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BACKGROUND OF THE INVENTION 



1. Field of the Invention 

The present invention relates in general to a replenishment management 
system, method, and program and more particularly to a replenishment management 
system, method, and program which provides just in time delivery to an acquiring 
10 entity, which may comprise a distribution center, wholesaler or any other supply chain 
system of components or products. 

2. Description of the Related Art 



15 challenge to the manufacturer of that product. Typically, delivery of components to 
the manufacturer usually involves three separate parties: the supplier, the 
replenishment service center ("warehouse or RSC") and the manufacturer. In the 
most basic sense, the availability of each component needs to be monitored to ensure 
an adequate supply is available to the manufacturer. The warehouse supplying the 

20 manufacturer and the supplier to the warehouse are further challenged to meet the 
demand for components without over stocking the components. However, 
maximizing the efficiency of delivering the components has been a constant problem 
in the prior art. For example, if the manufacturer finds either an increased or reduced 
demand in the product compared to its forecast, strain is placed throughout the supply 

25 chain where overstocking or depletion of components can occur quickly. In addition, 
if the supplier cannot deliver the components, manufacturers will often not be able to 
react quickly to meet demand, seek alternative sources, etc. Without keeping large 
stock of components on-hand in the warehouse, supply problems occur readily. 



Availability of components necessary to manufacture a product is a major 
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However, keeping large stock has additional problems of its own, such as higher 
storage costs, an increased loss probability because components become outdated, etc. 
Moreover, electronic parts tend to reduce in value with time (i.e. a part that the 
manufacturer purchases in January will cost less in March and much less in June and 
5 so on). 

Systems in the prior art have attempted to address this replenishment problem 
using various systems and methods. Internal MRP ("Material Requirement 
Planning") or ERP ("Enterprise Resource Planning") systems would manage 
components based on a forecast prepared by the manufacturer. However, forecasts 

10 are never precise, and often subject to changes. In recent years, to better match actual 
production with forecasts calculated by the MRP system, a Just-in-Time ("JIT") 
concept was developed. In a JIT environment, a network of phones and faxes is used 
to monitor each point in an assembly line where someone would be responsible for 
counting each set of components as they are assembled into a product (i.e. a manual 

15 pull system). Thereby, the responsible party would order additional components by 
phone or fax as components are running short. However, such JIT systems require 
constant monitoring, and still are highly dependent on accurate forecasts. Although 
better forecasting tools have been developed over the years, replenishment issues have 
remained a problem for manufacturers. As the manufacturing world begins to move 

20 to build-to-order environment, greater demands are expected from the manufacturer to 
1) lower total costs in the complete supply chain 2) shorten throughput times 3) 
reduce stock to a minimum and 4) provide more reliable delivery dates without 
constraining production due to supply issues. 

Accordingly, there is a need in the art for an improved replenishment 

25 management system that addresses the concerns of the supplier, the manufacturer, and 
the RSC. 
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SUMMARY OF THE PREFERRED EMBODIMENTS 
The present invention provides a system, method, and program for ordering 
or purchasing products between a manufacturer/distributer/etc (hereinafter "acquiring 
5 company"), a supplier, and a warehouse company (hereinafter Replenishment Service 
Center or RSC. To this end, an order to acquire a requested quantity of a specific 
product is generated by the acquiring entity. A product record is then generated in an 
inventory database which is updated to include information such as requested 
quantity, commitment quantity, and received quantity provided by the acquiring 

10 entity, supplier or RSC about the specific product. In addition, unlike prior art 
systems which depended purely on forecasts between the acquiring entity and 
supplier, the preferred embodiments calculate replenishment needs based on days of 
supply remaining at the RSC. Moreover, further embodiments are implemented in a 
network, such as the Internet, that allows the acquiring entity, supplier, or RSC to 

15 update and maintain current accurate information on a specific part in the database by 
means of a web tool, and which further facilitates communications among the 
acquiring entity, the replenishment service center, and the suppliers on a real time 
basis. In still further embodiments, invoices are automatically generated for the 
supplier as parts are pulled from the RSC to the acquiring entity reducing the amount 

20 of paperwork involved with the replenishment process. 

The preferred embodiments allow the acquiring entity to operate on a true 
"pull" or "kanban" basis. Advantages of the preferred embodiments include 
improved inventory reduction, higher turnover, in-house warehouse space reduction, 
handling cost reduction, and early detection of out of specification shipments for a 

25 acquiring entity. Additional advantages of the preferred embodiments include better 
communication between the supplier, warehouse, and acquiring entity throughout the 
component delivery process including ordering, delivery, and invoicing. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Referring now to the drawings in which like reference numbers represent 
corresponding parts throughout: 

FIG. 1 illustrates a network computing environment in which preferred 
5 embodiments are implemented; 

FIG. 2 illustrates a computing environment of a manufacturer server in 
accordance with preferred embodiments of the present invention; 

FIG. 3 illustrates files in a part record in accordance with preferred 
embodiments of the present invention; 
10 FIG. 4 illustrates a program flow implemented in the manufacturer server to 

provide information on forecasted and ordered parts to the supplier and replenishment 
service center in accordance with preferred embodiments of the present invention; 

FIG. 5 illustrates a program flow implemented in the manufacturer server to 
allow a supplier to commit to supplying requested parts and provide status 
15 information on the progress of delivering those parts to the replenishment service 
center in accordance with preferred embodiments of the present invention; 

FIG. 6 illustrates a program flow implemented in the manufacturer server to 
update parts information in a database from information provided by the supplier and 
replenishment service center in accordance with preferred embodiments of the present 
20 invention; 

FIG. 7 illustrates a program flow implemented in the manufacturer server to 
determine the days of supply for a part at the replenishment service center in 
accordance with preferred embodiments of the present invention; and 

FIG. 8 illustrates a program flow implemented in the manufacturer server to 
25 generate an invoice and payment for the manufacturer in accordance with preferred 
embodiments of the present invention; 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
In the following description, reference is made to the accompanying drawings 
which form a part hereof and which illustrate the preferred embodiment of the present 
invention. It is understood that other embodiments may be utilized and structural and 
5 operational changes may be made without departing from the scope of the present 
invention. 

FIG. 1 is a schematic overview diagram of the network computing 
environment in which the preferred embodiments are implemented. In preferred 
embodiments, a manufacturer server 10, a supplier computer 20, and replenishment 

10 service center ("RSC") computer 30 are linked together using a network 40, such as 
the Internet. The network 40 may be comprised of any network system known in the 
art including TCP/IP based networks (e.g., an Intranet, the Internet), LAN, Ethernet, 
WAN, Token Ring, etc. Alternatively, there may be separate and different networks 
between the components. Further, for a single part requested by the manufacturer, 

15 there can be numerous suppliers and RSCs, however a single supplier computer 20 
and single RSC computer 30 is used for illustration purposes. 

FIG. 2 illustrates software components in the manufacturer server 10 in which 
preferred embodiments are, including an Enterprise Resource Planning ("ERP") 
program 50, Hypertext Transfer Protocol (HTTP) server 52, database 60, database 

20 interface 70 and templates 65 and 67. The HTTP server 52 responds to requests from 
the supplier 20 and RSC 30 computers using HTTP client programs, such as web 
browser programs known in the art. Upon accessing the server 52 through the 
network 40 using a unique network address, such as an IP address, the database 
interface 70 will give specific access to database 60 depending on the secured 

25 identification provided by the supplier 20 or RSC 30 computers. 

The database 60 provides the manufacturer, supplier, and RSC with current, 
accurate information about the pipeline inventory necessary for the manufacturing 
process. The database 60 comprises a database program known in the art, such as a 
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relational database program. The database 60 includes a database table 61 that 
includes records 62a, b, .... n. The records 62a, b, ... n are used in the preferred 
embodiment as parts record 62a, b, ... n to store information about the component 
parts requested by the manufacturer and supplied by the supplier to the RSC 
5 throughout the replenishment process. 

The database interface 70 may comprise a Common Gateway Interface (CGI) 
program, a Java servlet, or other web page implementation known in the art to present 
the information in database 60 in a presentable format (e.g. HTML page, etc.). In 
preferred embodiments, the database interface 70 uses a secured login/password 
10 verification for identifying the individual supplier 20 or RSC 30 computer contacting 
the manufacturer's HTTP server 52. The unique identification will allow the database 
interface 70 to identify which parts record 62a, b, ... n belong to the requesting party 
and will appropriately give read/write capabilities to the parts record 62a, b, ... n. 



^ components required to manufacture of a determined number of a particular product 
over a specific period of time and prepares forecasts of the number of components 
required from each supplier. The ERP program 50 then places transfer orders for 
components from the RSC. In preferred embodiments, the ERP program 50 is 
20 capable of accessing the database 60 via a database interface system (not shown), 
such as the Open Database Connectivity (ODBC) standard database access method. 
The server 10 further stores a display template 65 and an input template 67, which are 
preferably implemented in a document in which dynamic content may be generated 
(i.e. HTML, Extended Markup Language (XML) Document, etc.). Differing 
25 variations of the display template 65 and input template 67 exists for both suppliers 
and RSCs, depending on the information to be displayed or inputted, but a single 
display template 65 and a single input template 67 are used for illustration purposes in 
FIG. 2. The display template 65 is used to provide the supplier 20 and RSC 30 




used by most manufacturers today. The ERP program 50 determines the quantity of 



The ERP program 50 is a common materials resource planning (MRP)_tool 
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computers with forecasts and past history reports generated by the ERP 50, as well as 
parts information from the database table 61. The database interface 70 generates 
data into the display template 65 from one or more of the records 62a, b, ... n in the 
database 60. The input template 67 includes fields in which the supplier 20 and RSC 
5 30 may enter information on the replenishment process which will be used to update 
one or more records 62a, b, ... n in the database 60. 

The database 60, display template 65, and input template 67 are preferably 
stored in a non-volatile storage system, such as one or more hard disk drives, used by 
the server 10 for storage. The server 10 may load data from v the storage system into 
10 volatile memory (not shown) when processing. 

The manufacturer 10, supplier 20 or RSC 30 computers may com prisejiny_ 
type of computer device known in the art, including server, personal computer, 
mainframe, workstation, hand held device, etc. Moreover, the manufacturer server 10 
may comprise one or more separate computer systems to run the different program 
15 components 50, 52, 60, and 70. 

As discussed, the part records 62a, b,...n may comprise fields containing 
/ 7^ information on parts used in the manufacturing of one or more products. The ERP 50 
may determine the exact number of parts needed upon receiving a request for a 
product order and then generate the parts records 62a, b,. ..n inc luding a purchase 
ZoJ 20 order for parts that will be needed to build the product. Thus, each part record 62a, b, 
...n is generated in response to a forecast for parts the manufacturer plans to use to 
build products. 

FIG. 3 provides an implementation of the fields in the parts records 62a^b, ... 
njiicluciing:- 

25 | Record ID HQ : Provides a unique identifier generated by the ERP 50 for the 

component part ordered by the manufacturer. 

P.O. Number 111 : Provides a unique identifier of the purchase order generated 
by the ERP 50 for parts needed to fulfill a manufacturer production goal. 



o Express Mail No. EL484 10621 1US 

Docket No. SJ09-2000-0173 
Firm No. 0035.0004 

Part Number 112 : Provides a unique identifier of the actual component part 
generated by the ERP 50. 

Su pplier ID 114 : Provides a unique identifier of the supplier who is to provide 
the component parts to the manufacturer. 
5 Forecasted Quantity 116 : Comprises one or more sub-fields indicating the 

projected quantity of parts required from the supplier by the manufacturer for 
a future designated time period. 

Date Needed 118 : Comprises one or more sub-fields indicating the date the 
part is needed at the RSC according to the forecast prepared by the ERP 50. 
10 Committed Quantity 120 : One or more sub-fields set by the supplier computer 

20 indicating the number of parts the supplier has committed to deliver to the 
RSC on specific dates. 

Shipment Information 122 : One or more sub-fields set by supplier computer 
20 providing tracking information on the delivery of components from the 

15 supplier to the RSC including method of shipment, carrier, port of entry, date 

of shipment and estimated time of arrival ("ETA"). / 
RSC Shipment Status 124 : Field set by RSC computer 30 indicating whether 
the components have been received or not from the supplier. 
Requested Quantity 125 : Projected quantity of parts to be requested from the 

20 RSC on specific dates to satisfy the production needs of the manufacturer. 

Pull Order Status 126 : One or more sub-fields set by the database interface 70 
indicating the pull status (i.e. status of the components being pulled from the 
RSC to the manufacturer) including whether the components have been 
ordered to be pulled or not (Pull In Requested Status), whether the RSC can 

25 fulfill the requested amount of components (Pull In Committed Status), 

whether the products are received or not at the manufacturer's dock (Pull In 
Shipped Status or Pull in Cancelled Status), as well as historic pull 
information (Pull History). 
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Available Inventory 127 : Indicates the amount of parts currently available at 



the RSC. 



Defective Notice 128 : Indicates the quantity of parts being returned as 



defective. 



Price 130 : Indicates the price per unit of component. 



Those skilled in the art will appreciate that FIG. 3 is a preferred embodiment of the 
record 62 a, b, ... n, but not as the only implementation. The record 62a, b, ... n can be 
structured in many alternative formats to accomplish the present invention. For 

10 example, the separate Available Inventory field 127 may not be needed and instead 
the value for the available inventory may just be calculated as needed by comparing 
the RSC Shipment Status 124 and the Pull Order Status 126. Another example is the 
Forecasted Quantity field 116 may be combined with the Requested Quantity field 
125 into a single field used by both the supplier and RSC rather than two separate 

15 fields for the supplier and RSC. 

Typically the forecasting and shipping process starts when the manufacturer 
makes a decision on the number of products it plans to build over a set of future time 
periods designated by the manufacturer. A blanket purchase order may be issued by 
the manufacturer to order the necessary components for the product. The ERP 

20 program 50 determines the number of components needed from each individual 
supplier, compares the number of parts needed with the number of parts committed 
from existing supplier contracts, and prepares a delivery schedule for each part. The 
ERP 50 then creates a separate record 62a, b, ...n for each part order in the database 
60. The data for the Record ID 1 10, P.O. No. 1 1 1, Part No. 1 12, Supplier ID 1 14, 

25 Forecasted Quantity 1 16 and Date Needed 1 18 is generated by the ERP program 50 
and stored in the appropriate part record 62a, b, ...n. 

FIGs. 4, 5, 6, 7, and 8 illustrate the program logic embedded in the ERP 
program 50, HTTP server 52, and database interface 70 to implement the 



4 
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replenishment process of the preferred embodiments. FIG. 4 illustrates the program 
logic to provide part record 62a, b,...n information to the supplier 20 and RSC 30 
computers. At block 400, the HTTP server 52 receives a request from the supplier 20 
or RSC 30 computer ("requesting party") for information on one or more part records 
5 62a, b,...n. The supplier 20 or RSC 30 computer may supply the record ID 1 10 or 
access a view of the part records in the database 60 and then select particular part 
records from the view. The HTTP server 52 may require a secured identification and 
password. At block 410, the database interface 70 accesses the display template 65 
and builds an HTML web page. The database interface program 70 queries (at block 

10 420) the database table 61 for the requested one or more records and then inserts (at 
block 430) the returned information into the display template. For example, when the 
supplier wants to view the forecast order placed by the manufacturer, the database 
interface 70 will search the database 60 on the Record ID 1 10 or Part No. 1 12 which 
matches the supplier computer's 20 search request. The database interface 70 will 

15 then build a HTML web page based on a display template 65 which will list a menu 
of information available to the supplier such as new forecast orders, commitment 
history, existing commitment outstanding, existing parts stored at the RSC, etc. The 
generated display page may include information such as the P.O. No. Ill, Supplier ID 
1 14, Forecasted Quantity 1 16 and Date Needed 118. 

20 FIG. 5 illustrates the program logic implemented in the HTTP server 52 and 

database interface 70 to receive commitment and part status information from the 
supplier for a part record. At block 500, the HTTP server 52 receives a request from 
the supplier computer 20 for the input page to provide commitment information with 
respect to a part record 62a, b, ...n. In response, the HTTP server 52 requests (at 

25 block 512) the database interface 70, which accesses the input template 67 and builds 
an HTML input page for the specified part record 62a, b, ... n. The built HTML input 
page is then sent to the supplier computer 20, where the supplier can enter 
commitment quantities for one or more part records. At block 514, the HTTP server 
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52 receives the HTML input page with the commitment quantities the supplier 
entered. In response, the HTTP server 52 requests the database interface 70 to update 
(at block 516) the commitment quantity field 120 of the relevant record with the 
information supplied by the supplier. 
5 At block 518, the database interface 70 determines if the Committed Quantity 

120 matches the Forecasted Quantity 116. If the supplier did not commit to the entire 
forecasted quantity 1 16, then the database interface 70 generates an exception view 
(at block 520) for all the uncommitted quantities. The manufacturer can then locate 
other suppliers to deliver the components or reduce product production to take into 

10 account that the supplier will not supply all the requested parts. The supplier may 
issue a shipment pre-alert document to the RSC personnel. This shipment pre-alert 
may specify when the supplier intends to make the shipment, the part number, 
quantity, etc. typically through an e-mail and/or fax. 

At some point, the supplier is going to ship the committed quantity to the 

15 RSC. The supplier can then input various shipping information into the database 60 
to confirm delivery to the RSC according to the terms of the supplier contract. The 
process initiates at block 550 where the HTTP server 52 receives a request for an 
input page from the supplier computer 20 to write in the shipment information 122 
covering the method of shipment, carrier, port of entry, date of shipment and ETA 

20 ("shipment tracking information") for one or more part records 62a, b,...n. At block 
552, the HTTP server 52 requests the database interface 70, which accesses an input 
template 67. The database interface 70 builds an HTML input page in which the 
supplier can enter shipment tracking information for the specified part record(s) 62a, 
b,...n. The HTTP server 52 then sends the input page back to the supplier computer 

25 20. At block 554, the HTTP server 52 receives the input page from the supplier 
computer 20 in which shipment information was entered. The HTTP server 52 then 
requests (at block 556) the database interface 70 to update the shipment information 
field 122 in the part records 62a, b,...n for which shipment information is provided in 
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the input page. Once shipment information is entered, the shipment or other 
information provided by the supplier is available to the manufacturer and RSC in the 
database 60. 

Once the components are ready, the supplier then ships the components to the 
5 RSC. The RSC will typically ensure that all necessary customs clearance and 
bonding documents are prepared in accordance with customs law regulations. An 
optional broker can be subcontracted by the RSC to facilitate the customs clearance 
process. Therefore, additional fields may exist in the Fulfillment Information 122 to 
indicate any potential broker used, customs requirement, etc. 

10 FIG. 6 illustrates the program logic implemented in the HTTP server 52 and 

database interface 70 to receive inventory information from the RSC computer 30 for 
each part. The RSC updates information in the part records 62a, b,...n upon receiving 
parts from the supplier or receiving a pull request for the parts from the manufacturer, 
which may be transmitted by the manufacturer server 10. The pull process is 

15 initiated when the manufacturer server 10 sends a Pull Order to the RSC computer 30, 
i.e. ordering the delivery of component parts stored at the RSC to the manufacturing 
floor of the manufacturer 102. The Pull Order is initiated by the ERP program 50 as 
parts are needed. The ERP program 50 then updates the Pull Order Status 126 as Pull 
Orders are issued. Typically, the RSC prepares the necessary documentation to 

20 provide a secure form of transportation from the RSC to the manufacturer's dock. 

At block 600, the HTTP server 52 receives a request from the RSC for an 
input page in which it can provide status information for part records 62a, b,...n as 
changes in the inventory occur at the RSC. The RSC computer 30 may request part 
record information as described in FIG. 4. The HTTP server 52 requests (at block 

25 602) the database interface 70 to access the input template 67 and builds an HTML 
input page in which the RSC may enter input information on whether the parts have 
been received from the supplier or parts were shipped to the manufacturer. At block 
604, the HTTP server 52 receives an input page including inventory information for 
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specified part record(s) 62a, b,...n, indicating parts received from the supplier or parts 
shipped to the manufacturer. The RSC provides information for RSC Shipment 
Status 124 or Pull Order Status 126. The database interface 70 (at block 606) updates 
the part record(s) 62a, b,..n with the RSC Shipment Status 124 or Pull Order Status 
5 126 from the RSC. The updated information is then available to the supplier and 
manufacturer in the database 60. 

At block 608, the database interface 70 will calculate the "Days of Supply" 
existing at the RSC, and determine whether the agreed "Days of Supply" exist at the 
RSC. Details of the calculation is given in Fig. 7. "Days of Supply" is the optimal 

10 amount of inventory to be held at the RSC by the supplier. The optimal amount is 
calculated by the manufacturer and negotiated with the supplier. Typically, the 
supplier will review the days of supply available at the RSC for its parts. If the 
available days of supply are less than the fixed days of supply agreed with the 
manufacturer, the supplier will ship parts to comply with the manufacturer's agreed 

15 Days of Supply. 

FIG. 7 illustrates the program logic implemented in the database interface 70 
to calculate the Days of Supply at the RSC according to the preferred embodiments. 
At block 700, the database interface 70 accesses the record 62 a, b, ... n for the 
particular part stored at the RSC. At block 702, the database interface 70 accesses the 

20 Available Inventory field 127 in the record 62 a, b, ... n. At block 706, the database 
interface 70 accesses the number of components to be pulled according to the 
Requested Quantity 125 in specific time period. At block 708, the Days of Supply is 
calculated by dividing the inventory available at the RSC by a weighted pull rate. The 
actual equation for the weighted pull rate is to be set by the manufacturer depending 

25 on the manufacturer's needs. For example, for a basic supply chain, the simplest 
formula for the weighted pull rate can be calculated by dividing the forecasted 
number of parts needed for the next Y number of weeks by the number of production 
days in those Y weeks to derive the Daily Going Rate ("DGR"). The Days of Supply 
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would then be calculated by dividing present inventory by the DGR. Alternatively, 
for a high volume manufacturer, the Days of Supply can be varied to assume that the 
next week forecast is already pulled and look further forward in time to calculate the 
Days of Supply. For example, the weighted pull rate can be calculated by dividing the 
5 forecasted number of parts needed in week number 2 (two weeks from current week) 
and week number 3 (three weeks from current week) by the number of production 
days in week number 2 and number 3. The Days of Supply is then calculated by first 
subtracting the forecasted number of parts needed in week number 1 (next week) from 
the present inventory at the RSC and then dividing by the weighted pull rate. Yet in 

10 other businesses where the manufacturer depends more on historic pull rates, another 
example exists where the weighted pull rate can be calculated by taking the average of 
the expected pull rate in the next X number of days or weeks and the actual pull rate 
in the past X number of days or weeks. Again, the Days of Supply is calculated by 
dividing the current inventory available at the RSC by the weighted pull rate. 

15 Therefore, without deviating from the scope of the present invention, there exists 
many variations in determining the Days of Supply depending on how the weighted 
pull rate is calculated, which ultimately depends on the needs of the manufacturer. 

Once the components are delivered from the RSC to the manufacturer, a 
physical product inspection may be performed. At which time, any damaged or 

20 defective component parts are sent back to the RSC. The defective notice field 128 of 
database 60 is then updated to reflect any returned component parts. The returned 
component parts are kept in a separate part of the RSC to either be reworked, scraped 
or returned back to the supplier, according to the supplier's instructions. If the 
component parts are deemed acceptable by the manufacturer, then a receipt of 

25 acceptance is issued by ERP 50. The ERP 50 then updates the database 60 to reflect 
the acceptance of the component parts. The database interface 70 updates the pull 
status 126 to reflect that the component parts or products were received by the 
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manufacturer. Thereby notice is given to both the RSC and supplier on the delivery 
of the components if they access the record 62 for the relevant shipment. 

FIG. 8 illustrates the program logic implemented in the HTTP server 52 and 
database interface 70 for the automatic invoicing and payment process according to 
5 the preferred embodiment. Once the receipt of the components are updated on part 
record 62a, b...n of the relevant shipment, the ERP 50 generates a goods receipt 
document and stores a price value in the price field 130 for part record 62a, b,...n. 
The database interface 70 will query the part records 62a, b...n for any pulls in status 
shipped for that supplier (block 800) and query the supplier about a specific invoice 

10 number and price information (block 805) which the supplier needs to provide. At 
block 810, the database interface 70 accesses an input template 67 and builds an 
HTML page which will have blanks next to the pre-invoice for the supplier 20 to 
confirm the invoice number and the unit price for the part. At block 820, the supplier 
computer 20 will input values for Price 130. At block 830, the database interface 70 

15 will then compare the values inputted by the supplier 20 with the values stored by the 
ERP program 50. If they match (block 840), then in block 850, an invoice document 
is automatically generated and payment to the supplier is processed according to the 
agreed upon payment term. The Pull Status 126 in database 60 will be updated from 
Shipped to Invoiced. If a discrepancy is found, at block 860, the Pull Status 126 is 

20 changed from Shipped to Buyer Pending, and the manufacturer is given the 

opportunity to approve or reject the difference in the part's price (block 870). A 
supplier representative can also contact the manufacturer to reconcile the differences. 
Once an agreement is made (i.e. a match according to block 840), an invoice 
document can be produced according to block 850. The ability to invoice through the 

25 database driven inventory system substantially simplifies the payment process and 
allows greater efficiency in the replenishment process. 

Those skilled in the art will again appreciate that alternative embodiments 
exists from the description of the preferred embodiments without departing from the 
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spirit and scope of the invention. The preferred embodiments may be implemented as 
a method, apparatus or article of manufacture using standard programming and/or 
engineering techniques to produce software, firmware, hardware, or any combination 
thereof. The term "article of manufacture" (or alternatively, "computer program 
5 product") as used herein is intended to encompass one or more computer programs 
and data files accessible from one or more computer-readable devices, carriers, or 
media, such as a magnetic storage media, "floppy disk," CD-ROM, a file server 
providing access to the programs via a network transmission line, holographic unit, 
etc. Of course, those skilled in the art will recognize that many modifications may be 

10 made to this configuration without departing from the scope of the present invention. 

Preferred embodiments were shown in the context of network system, where 
all of the communications were performed through computers located at the supplier, 
RSC, and the manufacturer. However, in alternative embodiments, many of the 
functions can be performed by other means of communication such as telephone, fax, 

15 e-mail, etc by operators located at the supplier, RSC, or manufacturer. For example, 
the supplier may directly call an operator at the manufacturer to give commitment 
values, shipment information, etc. rather than entering the values through the network 
by means of the supplier computer. The RSC or manufacturer may directly contact 
each other by phone, fax, e-mail, etc. for current inventory levels, pull order status, 

20 etc. rather than using the computer network. 

In the described embodiments, a manufacturer was the entity that acquired 
parts from the RSC using the computerized database inventory management system of 
the preferred embodiments. In alternative embodiments, the computerized database 
inventory management system may be used by any acquiring entity and the parts 

25 being ordered may comprise products or supplies being acquired by the acquiring 

entity. For instance, the acquiring entity, in addition to being a manufacturer, can be 
a distributor or wholesaler or any other party having a supply chain. A hospital or a 
retail store may house its supplies/inventory at a warehouse and use the preferred 
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embodiment database inventory system to order additional supplies as they are either 
used or sold off the shelves. Thus, the acquiring entity may encompass any entity that 
controls inventory process throughout the supply chain. Similarly, the RSC can be 
directly owned by either the supplier or manufacturer or third party, but the ownership 
5 does not effect its function or ability in the present invention. 

Preferred embodiments were described with respect to the database interface 
70 performing the computation regarding the Days of Supply, generating the 
Exception View, etc. However, in alternative embodiments, some of the functions of 
the database interface may be implemented in the ERP program, a separate software 

10 program or eliminated altogether. Alternatively, the functions shown may be 
combined or split in any manner amongst one or more systems. 

In addition, preferred embodiments described the parts information describing 
the files as implemented as database records in a database table. However, the parts 
information may be implemented in any format for maintaining object information, 

15 including spreadsheet, non-database table, etc. Thus, as used herein, the terms 

database record, database table, and database refer to any data structure known in the 
art for maintaining information on data objects, such as relational databases, non- 
relational databases, spreadsheets, ASCII text files, etc. 



20 invention has been presented for the purposes of illustration and description. It is not 
intended to be exhaustive or to limit the invention to the precise form disclosed. 
Many modifications and variations are possible in light of the above teaching. It is 
intended that the scope of the invention be limited not by this detailed description, but 
rather by the claims appended hereto. The above specification, examples and data 

25 provide a complete description of the manufacture and use of the composition of the 
invention. Since many embodiments of the invention can be made without departing 
from the spirit and scope of the invention, the invention resides in the claims 
hereinafter appended. 



Therefore, the foregoing description of the preferred embodiments of the 



